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Abstract 


This document defines an RTP Control Protocol (RTCP) Extended Report 
(XR) block that allows reporting of a post-repair loss count metric 
for a range of RTP applications. In addition, another metric, 
repaired loss count, is also introduced in this report block for 
calculating the pre-repair loss count when needed, so that the RTP 
sender or a third-party entity is able to evaluate the effectiveness 
of the repair methods used by the system. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7509. 
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1. Introduction 


RTCP Sender Reports (SRs) / Receiver Reports (RRs) [RFC3550] contain 
some rough statistics about the data received from the particular 
source indicated in that block. One of them is the cumulative number 
of packets lost, which is called the pre-repair loss metric in this 
document. This metric conveys information regarding the total number 
of RTP data packets that have been lost since the beginning of the 
RTP session. 


However, this metric is measured on the media stream before any loss- 
repair mechanism, e.g., retransmission [RFC4588] or Forward Error 
Correction (FEC) [RFC5109], is applied. Using a repair mechanism 
usually results in recovering some or all of the lost packets. The 
recovery process does not reduce the values reported by the two loss 
metrics in RTCP RR [RFC3550] -- namely, the fraction lost and the 
cumulative loss. Hence, the sending endpoint cannot infer the 
performance of the repair mechanism based on the aforementioned 
metrics in [RFC3550]. 


Consequently, [RFC5725] specifies a post-repair loss Run-Length 
Encoding (RLE) XR report block to address this issue. The sending 
endpoint is able to infer which packets were repaired from the RLE 
report block, but the reporting overhead for the packet-by-packet 
report block is higher compared to other report blocks. 
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When applications use multiple XR blocks, the endpoints may require 
more concise reporting to save bandwidth. This document defines a 
new XR block type to augment those defined in [RFC3611] and 
complement the report block defined in [RFC5725] for use in a range 
of RTP applications. This new block type reports the post-repair 
loss count metric, which records the number of primary source RTP 
packets that are still lost after applying one or more loss-repair 
mechanisms. In addition, another metric, repaired loss count, is 
also introduced in this report block for calculating the pre-repair 
loss count during this range, so that the RIP sender or a third-party 
entity is able to evaluate the effectiveness of the repair methods 
used by the system. The metrics defined in this document are packet 
level rather than slice/picture level; this means the partial 
recovery of a packet will not be regarded as a repaired packet. 


The metrics defined in this document belong to the class of 
transport-related metrics defined in [RFC6792] and are specified in 
accordance with the guidelines in [RFC6390] and [RFC6792]. These 
metrics are applicable to any RTP application, especially those that 
use loss-repair mechanisms. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [KEYWORDS]. 


primary source RTP packet: The original RTP packet sent from the RTP 
sender for the first time. A lost primary source RTP packet may 
be repaired by some other RTP packets used in repair mechanisms 
like FEC or retransmission. 


3. Post-Repair Loss Count Metrics Report Block 


This block reports the number of packets lost after applying repair 
mechanisms (e.g., FEC). It complements the RICP XR metrics defined 
in [RFC5725]. As noted in [RFC5725], ambiguity may occur when 
comparing this metric with a pre-repair loss metric reported in an 
RTCP SR/RR, i.e., some packets were not repaired in the current RTCP 
interval, but they may be repaired later. Therefore, this block uses 
a begin sequence number and an end sequence number to explicitly 
indicate the actual sequence number range reported by this RTCP XR. 
Accordingly, only packets that have no further chance of being 
repaired and that have been repaired are included in this report 
block. 
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3.1. Report Block Structure 


The Post-Repair Loss Count Metrics Report Block has the following 


format: 
0 1 2 3 4 
Yaa ae oA Si se arc aN Oa ees ee so SO Ms ee i ie 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| BT=33 | Reserved | Block length = 4 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| SSRC of Source | 
+-+-+-+-+-+-+-+- ++ 


| begin_seq | end_seq | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+H+HHHH HHHMH MHH 
| Post-repair loss count | Repaired loss count 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Block Type (BT): 8 bits 


A Post-Repair Loss Count Metrics Report Block is identified by the 
constant 33. 


Reserved: 8 bits 


These bits are reserved for future use. They MUST be set to zero 
by senders and ignored by receivers (see Section 4.2 of 
[RFC6709]). 


Block length: 16 bits 
This field is in accordance with the definition in [RFC3611]. In 
this report block, it MUST be set to 4. The block MUST be 
discarded if the block length is set to a different value. 

SSRC of source: 32 bits 
As defined in Section 4.1 of [RFC3611]. 


begin_seq: 16 bits 


The first sequence number that this block reports on. It can 
remain fixed when calculating metrics over several RTCP reporting 
intervals. 


end_seq: 16 bits 


The last sequence number that this block reports on plus one. 
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Post-repair loss count: 16 bits 


Total number of packets finally lost after applying one or more 
loss-repair methods, e.g., FEC and/or retransmission, during the 
actual sequence number range indicated by begin_seq and end_seq. 
This metric MUST NOT count the lost packets for which repair might 
still be possible. Note that this metric MUST measure only 
primary source RTP packets. 


Repaired loss count: 16 bits 


Total number of packets fully repaired after applying one or more 
loss-repair methods, e.g., FEC and/or retransmission, during the 
actual sequence number range indicated by begin_seq and end_seq. 
Note that this metric MUST measure only primary source RTP 
packets. 


3.2 Example Usage 


The metrics defined in this report block are all measured at the RTP 
receiver. However, the receiving endpoint can report the metrics in 
two different ways: 


1) Cumulative report 


In this case, implementations may set begin_seq to the first packet 
in the RTP session, and it will remain fixed across all reports. 
Hence, the "Post-repair loss count" and "Repaired loss count", 
respectively, will correspond to "Cumulative post-repair loss count" 
and "Cumulative repaired loss count" in this case. These cumulative 
metrics when combined with the cumulative loss metrics reported in an 
RTCP RR (pre-repair) assist in calculating the "Still-to-be-repaired 
lost packets": 


Still-to-be-repaired lost packets = 
Cumulative number of packets lost - 
Cumulative post-repair loss count - 
Cumulative repaired loss count 


2) Interval report 


Some implementations may align the begin_seq and end_seq number with 
the highest sequence numbers of consecutive RTCP RRs (RTCP interval). 
This is NOT RECOMMENDED as packets that are not yet repaired in this 
current RTCP interval and may be repaired in the subsequent intervals 
will not be reported. An interval report is illustrated in the 
following example: 
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Interval A: The extended highest sequence number received in RTCP 
RR is 20. Begin_seq is 10 and end_seq is 20. 


Interval B: The extended highest sequence number received in RTCP 
RR is 30. Begin_seq is 20 and end_seq is 30. 


If packets 17 and 19 are lost and not yet repaired in interval A and 
subsequently repaired in interval B, they will not be reported 
because their sequence numbers do not belong in interval B. 
Therefore, if implementations want these packets to be reported as 
repaired, they MUST NOT align the begin_seq and end_seq to the RTCP 
intervals. 


Alternatively, implementations may choose the begin_seq and end_seq 
numbers that cover several RTCP intervals. Additionally, the 
reported range of sequence numbers may overlap with the previous 
report blocks, so that the packets that were not yet repaired in one 
interval, but were subsequently repaired or deemed unrepairable, were 
reported in subsequent intervals. 


In this case, the "Cumulative number of packets lost" cannot be 
easily compared with the post-repair metrics. However, the sending 
endpoint can calculate the efficiency of the error resilience 
algorithm using the post-repair and repaired loss count, 
respectively. 


4. SDP Signaling 
[RFC3611] defines the use of SDP (Session Description Protocol) for 
signaling the use of RTCP XR blocks. However, XR blocks MAY be used 
without prior signaling (see Section 5 of [RFC3611]). 

4.1. SDP rtcp-xr-attrib Attribute Extension 
This session augments the SDP attribute "rtcp-xr" defined in Section 
5.1 of [RFC3611] by providing an additional value of "xr-format" to 
signal the use of the report block defined in this document. The 
ABNF [RFC5234] syntax is as follows. 


xr-format =/ xr-prlr-block 


xr-prlr-block = "post-repair-loss-count" 
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4.2. Offer/Answer Usage 


When SDP is used in offer/answer context, the SDP Offer/Answer usage 
defined in [RFC3611] for the unilateral "rtcp-xr" attribute 
parameters applies. For detailed usage of Offer/Answer for 
unilateral parameters, refer to Section 5.2 of [RFC3611]. 


5. Security Considerations 


This proposed RTCP XR block introduces no new security considerations 
beyond those described in [RFC3611]. This block does not provide 
per-packet statistics, so the risk to confidentiality documented in 
Section 7, paragraph 3 of [RFC3611] does not apply. 


An attacker may put incorrect information in the Post-Repair Loss 
Count reports, which will affect the performance of loss-repair 
mechanisms. Implementers should consider the guidance in [RFC7202] 
for using appropriate security mechanisms, i.e., where security is a 
concern, the implementation should apply encryption and 
authentication to the report block. For example, this can be 
achieved by using the AVPF profile together with the Secure RTP 


profile as defined in [RFC3711]; an appropriate combination of the 
two profiles (an "SAVPF") is specified in [RFC5124]. However, other 
mechanisms also exist (documented in [RFC7201]) and might be more 
suitable. 


6. IANA Considerations 
New block types for RTCP XR are subject to IANA registration. For 
general guidelines on IANA considerations for RTCP XR, refer to 
[RFC3611]. 

6.1. New RTCP XR Block Type Value 
This document assigns the block type value 33 in the IANA "RTP 
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 
the "Post-Repair Loss Count Metrics Report Block". 

6.2. New RTCP XR SDP Parameter 
This document also registers a new parameter "post-—repair-—loss-count" 
in the "RTP Control Protocol Extended Reports (RTCP XR) Session 
Description Protocol (SDP) Parameters Registry". 


6.3. Contact Information for Registrations 


The contact information for the registrations is: 
RAI Area Directors <rai-ads@ietf.org> 
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Appendix A. Metrics Represented Using the Template from RFC 6390 


a. Post-Repair RTP Packet Loss Count Metric 


* 


Metric Name: Post-Repair RTP Packet Loss Count Metric. 


Metric Description: Total number of RTP packets still lost 
after loss-repair methods are applied. 


Method of Measurement or Calculation: See the "Post-repair 
loss count" definition in Section 3.1. It is directly 
measured and must be measured for the primary source RTP 
packets with no further chance of repair. 


Units of Measurement: This metric is expressed as a 16-bit 
unsigned integer value giving the number of RTP packets. 


Measurement Point(s) with Potential Measurement Domain: It is 
measured at the receiving end of the RTP stream. 


Measurement Timing: This metric relies on the sequence number 
interval to determine measurement timing. See the Cumulative 
and Interval reports defined in Section 3.2. 


Use and Applications: These metrics are applicable to any RTP 
application, especially those that use loss-repair mechanisms. 


See Section 1 for details. 


Reporting Model: See RFC 3611. 


b. Repaired RTP Packet Loss Count Metric 


* 


Metric Name: Repaired RTP Packet Count Metric. 


Metric Description: The number of RTP packets lost but 
repaired after applying loss-repair methods. 


Method of Measurement or Calculation: See the "Repaired loss 
count" in Section 3.1. It is directly measured and must be 
measured for the primary source RTP packets with no further 
chance of repair. 


Units of Measurement: This metric is expressed as a 16-bit 
unsigned integer value giving the number of RTP packets. 


Measurement Point(s) with Potential Measurement Domain: It is 
measured at the receiving end of the RTP stream. 
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* Measurement Timing: This metric relies on the sequence number 
interval to determine measurement timing. See the Cumulative 
and Interval reports defined in Section 3.2. 


* Use and Applications: These metrics are applicable to any RTP 
application, especially those that use loss-repair mechanisms. 
See Section 1 for details. 


* Reporting Model: See RFC 3611. 
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